Adds support for additional byond versions tests

## About The Pull Request

It is possible to create a callback whose `object` (the datum it tries
to call) is a path to an external library. Needless to say, it's
probably a bad idea to allow admins to call arbitrary external
libraries. Var-edited callbacks won't be able to reach the point where
the library is executed, but only because `WrapAdminProcCall` runtimes
when trying to call `CanProcCall` on a string, but if there is some way
to call a function that creates a non-varedited callback with an
external library as its object, this PR prevents that.

## Why It's Good For The Game

See above.

## Changelog

:cl:
admin: Admins are unable to invoke functions from external libraries
using callbacks.
/:cl:

It is possible to create a callback whose `object` (the datum it tries
to call) is a path to an external library. Needless to say, it's
probably a bad idea to allow admins to call arbitrary external
libraries. Var-edited callbacks won't be able to reach the point where
the library is executed, but only because `WrapAdminProcCall` runtimes
when trying to call `CanProcCall` on a string, but if there is some way
to call a function that creates a non-varedited callback with an
external library as its object, this PR prevents that.

See above.

:cl:
admin: Admins are unable to invoke functions from external libraries
using callbacks.
/:cl:

This is a byond bug, but @san7890 @lessthnthree found it months ago and
didn't report it to byond.

So I will not open the issue report reporting this byond. They can
fucking do that.

This pr needs a speed merge because we have linux downstreams that
follow upstream code affected by this byond bug. then again skyrat also
knows about this bug on top of this workaround and has not opened a bug
report so maybe they don't fucking need a speed merge and instead should
have filed a bug report with byond.

Its out of my hands.

---------

Co-authored-by: Watermelon914 <[email protected]>